作為軟體工程師的我們應該都曾有過一個疑問，開始寫程式之前，要不要先做規劃。
這個問題也曾經困擾著我跟我的朋友。如果不做規劃，可能會導致程式雜亂不易維護。
若做了規劃，又可能花費大量的時間與精力，可能還不敷成本。

某個陽光明媚的上午，朋友突然找我討論起要不要做UML的話題(簡單翻譯就是程式的藍圖)
朋友: 欸，你不覺得寫UML很浪費時間嗎?
我: 是很花時間。
朋友: 你會Coding前會畫Class(類別圖)嗎?
我: 不會。
朋友: UseCase(使用者案例)?
我: 不會。
朋友: 那...
我: 不會。
朋友: 對吧，不如直接邊寫邊想就好，做一堆文件浪費時間。
我: 還是會先寫一下流程圖。
朋友: !@#$%....剛剛不會先等我問完喔...

制定目標

在上一篇(尋找日常生活中的問題)，
我們提到老闆可能因為某些原因掉單。所以我們為了解決那些問題要來開發一套程式。
首先，老闆可能因為字醜，或是紙張飄掉的問題改成電子化就解決了。
但是人多的時候，即便改成電子化，依然有可能會忘記寫。
所以我們這邊更改一下作業方式，開發成一個網頁版的菜單，
讓客戶可以在上面點餐，這樣不用擔心電話被佔線問題打不進來，
也不用擔心，老闆在忙的時候忘記了。(把問題丟給客戶，這樣就沒問題了)
所以我們決定做一個網頁讓客戶可以在網頁上點餐，這樣子初步的目標就訂好了。

如何評估可行性

在職場上很常看到業務/業務工程師，之類的職位出去跟客戶說得天花亂墜，
回來之後再把問題丟給開發人員，把自家工程師當作007去解不可能的任務。
會出現這樣的問題，最主要的原因是他們在與客戶討論需求時，沒有做可行性的評估。

做評估的時候其實就兩件事:

1. 建立 步驟/流程
2. 檢視 步驟的合理性

建立 步驟/流程

為了避免不可能的任務，在開始之前我們需要建構出一個可走到終點的步驟。
以這次的題目為例，我們可以開始思考當這個專案如果真實運行時應該會是怎樣的流程。

首先，我們打開網頁，在網頁的畫面上點了我們要的菜單之後送出。
之後老闆在網頁上看到我們的單子，開始做我們的餐點，做完之後我們取餐。
接下來把它整理成步驟:

1. 打開網頁點餐
2. 老闆接收到單子
3. 老闆做餐點
4. 取餐

這樣就完成了我們整個流程了，這邊有一點很重要就是一定要有開始，有結束。
很多人最常犯的問題就是只把流程寫到，想要呈現的功能就結束了。
例如，最常聽到業務工程師都是這樣說需求。
客戶要能夠打開網頁，進去之後上面要有Button可以按，下面要有下拉式選單，旁邊要有公司電話.....等。
要是你問客戶說客戶需求就這樣?
他們可能還會說:就這樣阿，不然你還要甚麼?
這樣有頭沒尾的，又說了一堆可能會更動的細節，不僅會造成開發時候的混亂。
等哪天，真的工程師開發出這種一堆按鍵卻沒有功能的程式交差時，就準備大家頭痛了。

所以千萬千萬要記住有開頭也要有結尾。

檢視 步驟的合理性

在檢查步驟合理性的時候，有一個比較簡單的方法，
就是去觀察資料(data)的流向，在這邊資料就是我們點餐的單子。

我們來跑一次前面的步驟:

1. 打開網頁點餐 (客戶建立單子)
2. 老闆接收到單子(單子送到老闆這)
3. 老闆做餐點(單子依然在老闆這)
4. 取餐(單子依然在老闆這)

(雖然看起來有點怪怪的，但不知道問題在哪裡~~~)
那我們再跑一次:
打開網頁點餐 (第二個客戶建立單子)
2. 老闆接收到單子(此時老闆會發現，有兩筆單子)
3. 老闆做餐點(還是兩筆單子)
4. 取餐(還是兩筆單子)

這時候我們就會發現好像出了個問題，那就是當我們完成單子的時候沒有把單子刪除。

所以我們修改一下我們的步驟:

1. 打開網頁點餐
2. 老闆接收到單子
3. 老闆做餐點
4. 取餐
5. 標示已完成的單子

這個例子是一個很常見的思考盲區，會把平常時習以為常的事情給忘記了(但還是有做)。
這可能就會導致做出不如預期的成果。
這時我們透過觀察資料流向的方式，可以比較容易發現流程上的錯誤。

結語

我們可以透過畫流程圖，或是建立一個一個的步驟來確定我們是否能達到我們要的目標。
之後透過檢查資料的流向來確定我們的步驟是否合理。

這篇我們沒有任何程式的元素，
下篇開始我們會進入程式的角度來看看我們應該要如何規劃